perm filename QUESTI[RDG,DBL] blob sn#520793 filedate 1980-08-22 generic text, type C, neo UTF8
COMMENT āŠ—   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	Mailed to CSD.GENESERETH, CSD.SMITH 13:38 17-June
C00005 ENDMK
CāŠ—;
Mailed to CSD.GENESERETH, CSD.SMITH 13:38 17-June
Proposition:

	RLL will come with a large (and extendable) set of Simulation Structures.
The initial ("top level") SS (that is, the starting setting for the
organ,) defines each SS as a set of linguistic elements (which are the set of
LISP functions,) only some of which have a semantic interpretation. That subset
is different for each SS; as is the actual interpretation.
(Hence, RDG's RLL has defined GetValue and PutValue, whereas MRG's version makes
no effort to define these, and instead worries about True and Value.)

	These functions are used to access the information in the KB;
each SS somehow states that all the other symbols of LISP are
available to the user, but does not provide these linguistic elements
with any (pre-defined) semantics. 

	When creating a new KB, the user may
(1) indicate which SS he wishes
(2) indicate this KB will have a new type of SS - and will proceed to 
	to define it (using mechanisms of the current SS.)

Questions:
1) Does this seem feasible? Is it basically what you had in mind? What would you
	want to change?

2) Should each KB have exactly 1 Simulation Structure associated with it?
	Is this a limitation - when might a user wish a single KB to have 
	more than one SS?
3) How many functions should there be for accessing the KB? I believe this
	number should be small, and these functions should have a good "semantics".

Comments in general.